home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 1816 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB

  1. Path: gate.net!pslfl2-8
  2. From: bhutto@gate.net (William Hutto)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Runtime error when stressing application
  5. Date: 17 Jan 1996 00:07:13 GMT
  6. Organization: CyberGate, Inc.
  7. Message-ID: <4dhejh$18p2@news.gate.net>
  8. References: <4dgdjd$1ko@erinews.ericsson.se>
  9. NNTP-Posting-Host: pslfl2-34.gate.net
  10. X-Newsreader: News Xpress Version 1.0 Beta #4
  11.  
  12. In article <4dgdjd$1ko@erinews.ericsson.se>,
  13.    ebcjeg@ebc.ericsson.se (Jan Granqvist) wrote:
  14. >Hello everybody.
  15. >
  16. >I've received this strange fault which occurs when stressing this
  17. >application I'm working on, which runs under windows.
  18. >
  19. >To make things short.
  20. >I call lstrlen ( pointer ), where pointer is composed by combining a
  21. >pointer and an offset.
  22. >
  23. >    dwDestAddressSize = lstrlen( (LPCSTR)(lp_ForwardingInfo + dwOffset ))
  24.  
  25. Not knowing what type lp_ForwardingInfo is, I'll guess it points to something 
  26. 0x18 bytes in size. Right? If your compiler does pointer arithmetic properly, 
  27. it did exactly what you told it to. If you want to do the pointer arithmetic 
  28. yourself as such, you should first cast lp_ForwardingInfo to LPCSTR assuming 
  29. that resolves to a BYTE size granularity. e.g.:
  30.  
  31.     dwDestAddressSize = lstrlen( ((LPCSTR)lp_ForwardingInfo)+ dwOffset );
  32.  
  33. Assuming that the sizeof(*lp_ForwardingInfo) is 0x18, did you realize that if 
  34. dwOffset had been 1 it would have yielded the correct results (in your 
  35. example)? It (the compiler) apparantly multiplied dwOffset by 0x18 which made 
  36. me think you must have been trying to access the second element in an array 
  37. (lp_ForwardingInfo[1]). The compiler thought you were trying to access the 
  38. 25th element (lp_ForwardingInfo[24]), which happens to be the difference 
  39. between the base (0x0910) and the value you passed to this function (0x0B50). 
  40. The compiler will do the math for you if you let it.
  41.  
  42. Bill
  43.  
  44. >+ 1;
  45. >
  46. >When stressing this application CodeGuard complains about an invalid
  47. >string pointer.
  48. >So, I changed from lstrlen to strlen, which resulted in a GPF, which
  49. >in turn I could catch in the debugger.
  50. >
  51. >The call stack indicated a fault in strlen. I took a look at the
  52. >stack, and saw that the
  53. >argument pushed on the stack was wrong, the offset to the pointer was
  54. >totally wrong, the segment was however correct.
  55. >
  56. >d SS:BP
  57. >
  58. >    0x43A7        correct segment value
  59. >    0x0B50        wrong offset value, should have been 0x0928
  60. >    0x47C7        return address
  61. >    0x4235        return address
  62. >
  63. >So, I took a look on the variables which creates the argument to
  64. >strlen, and these showed the proper values.
  65. >
  66. >    lp_ForwardList    0x43A7:0x0910
  67. >    dwOffset    0x18
  68. >
  69. >I then created a dummy variable
  70. >
  71. >    lpDummy = (LPCSTR)(lp_ForwardingInfo + dwOffset );
  72. >    lpDummy = lpDummy;
  73. >
  74. >to see if it always came up with this result. And, it did. But still
  75. >the variables for creating the dummy variable were right. So, I
  76. >thought to myself, weird shit.
  77. >I was thinking about a corrupt stack, but the return address and
  78. >segment values were right.
  79. >I then created a dummy function with three arguments
  80. >
  81. >    void myfunc ( DWORD, LPSTR, DWORD );
  82. >
  83. >that only calls strlen, which I called
  84. >
  85. >    myfunc ( dwResult, (LPSTR)lp_ForwardingInfo, dwOffset );
  86. >
  87. >to see which values pushed on the stack were wrong.
  88. >But after I did this small change, it works, I couldn't get a GPF.
  89. >Now, somebody tell me, what's going on.
  90. >
  91. >It was compiled using VC++ 1.51, large model, no optimization.
  92. >
  93. >I'm waiting eagerly for reply.
  94. >
  95. >
  96.